home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxx / rfc947 < prev    next >
Text File  |  1995-07-25  |  13KB  |  286 lines
  1.  
  2.  
  3. Network Working Group                                       Ken Lebowitz
  4. Request for Comments: 947                                  David Mankins
  5.                                                         BBN Laboratories
  6.                                                                June 1985
  7.  
  8.              Multi-network Broadcasting within the Internet
  9.  
  10.  
  11. 1. Status of this Memo
  12.  
  13.    This RFC describes the extension of a network's broadcast domain to
  14.    include more than one physical network through the use of a broadcast
  15.    packet repeater.
  16.  
  17.    The following paper will present the problem of multi-network
  18.    broadcasting and our motivation for solving this problem which is in
  19.    the context of developing a distributed operating system.  We discuss
  20.    different solutions to extending a broadcast domain and why we chose
  21.    the one that has been implemented.  In addition, there is information
  22.    on the implementation itself and some notes on its performance.
  23.  
  24.    It is hoped that the ideas presented here will help people in the
  25.    Internet who have applications which make use of broadcasting and
  26.    have come up against the limitation of only being able to broadcast
  27.    within a single network.
  28.  
  29.    The information presented here is accurate as of the date of
  30.    publication but specific details, particularly those regarding our
  31.    implementation, may change in the future.  Distribution of this memo
  32.    is unlimited.
  33.  
  34. 2. The Problem
  35.  
  36.    Communication between hosts on separate networks has been addressed
  37.    largely through the use of Internet protocols and gateways. One
  38.    aspect of internetwork communication that hasn't been solved in the
  39.    Internet is extending broadcasting to encompass two or more networks.
  40.    Broadcasting is an efficient way to send information to many hosts
  41.    while only having to transmit a single packet.  Many of the current
  42.    local area network (LAN) architectures directly support a broadcast
  43.    mechanism.  Unfortunately, this broadcast mechanism has a shortcoming
  44.    when it is used in networking environments which include multiple
  45.    LANs connected by gateways such as in the DARPA Internet.  This
  46.    shortcoming is that broadcasted packets are only received by hosts on
  47.    the physical network on which the packet was broadcast.  As a result,
  48.    any application which takes advantage of LAN broadcasting can only
  49.    broadcast to those hosts on its physical network.
  50.  
  51.    We took advantage of broadcasting in developing the Cronus
  52.    Distributed Operating System [1].  Cronus provides services and
  53.    communication to processes distributed among a variety of different
  54.  
  55.  
  56. Lebowitz & Mankins                                              [Page 1]
  57.  
  58.  
  59.  
  60. RFC 947                                                        June 1985
  61. Multi-network Broadcasting within the Internet
  62.  
  63.  
  64.    types of computer systems.  Cronus is built around logical clusters
  65.    of hosts connected to one or more high-speed LANs.  Communication in
  66.    Cronus is built upon the TCP and UDP protocols.  Cronus makes use of
  67.    broadcasting for dynamically locating resources on other hosts and
  68.    collecting status information from a collection of servers.  Since
  69.    Cronus's broadcast capabilities are not intended to be limited to the
  70.    boundaries of a single LAN, we needed to find some way to extend our
  71.    broadcasting domain to include hosts on distant LANs in order to
  72.    experiment with clusters that span several physical networks.  Cronus
  73.    predominantly uses broadcasting to communicate with a subset of the
  74.    hosts that actually receive the broadcasted message.  A multicast
  75.    mechanism would be more appropriate, but was unavailable in some of
  76.    our network implementations, so we chose broadcast for the initial
  77.    implementation of Cronus utilities.
  78.  
  79. 3. Our Solution
  80.  
  81.    The technique we chose to experiment with the multi-network
  82.    broadcasting problem can be described as a "broadcast repeater".  A
  83.    broadcast repeater is a mechanism which transparently relays
  84.    broadcast packets from one LAN to another, and may also forward
  85.    broadcast packets to hosts on a network which doesn't support
  86.    broadcasting at the link-level.  This mechanism provides flexibility
  87.    while still taking advantage of the convenience of LAN broadcasts.
  88.  
  89.    Our broadcast repeater is a process on a network host which listens
  90.    for broadcast packets.  These packets are picked up and
  91.    retransmitted, using a simple repeater-to-repeater protocol, to one
  92.    or more repeaters that are connected to distant LANs.  The repeater
  93.    on the receiving end will rebroadcast the packet on its LAN,
  94.    retaining the original packet's source address.  The broadcast
  95.    repeater can be made very intelligent in its selection of messages to
  96.    be forwarded.  We currently have the repeater forward only broadcast
  97.    messages sent using the UDP ports used by Cronus, but messages may be
  98.    selected using any field in the UDP or IP headers, or all IP-level
  99.    broadcast messages may be forwarded.
  100.  
  101. 4. Alternatives to the Broadcast Repeater
  102.  
  103.    We explored a few alternatives before deciding on our technique to
  104.    forward broadcast messages.  One of these methods was to put
  105.    additional functions into the Internet gateways.  Gateways could
  106.    listen at the link-level for broadcast packets and relay the packets
  107.    to one or more gateways on distant LANs.  These gateways could then
  108.    transmit the same packet onto their networks using the local
  109.    network's link-level broadcast capability, if one is available.  All
  110.    gateways participating in this scheme would have to maintain tables
  111.  
  112.  
  113. Lebowitz & Mankins                                              [Page 2]
  114.  
  115.  
  116.  
  117. RFC 947                                                        June 1985
  118. Multi-network Broadcasting within the Internet
  119.  
  120.  
  121.    of all other gateways which are to receive broadcasts.  If the
  122.    recipient gateway was serving a network without a capacity to
  123.    broadcast it could forward the messages directly to one or more
  124.    designated hosts on its network but, again, it would require that
  125.    tables be kept in the gateway.  Putting this sort of function into
  126.    gateways was rejected for a number of reasons: (a) it would require
  127.    extensions to the gateway control protocol to allow updating the
  128.    lists gateways would have to maintain, (b) since not all messages
  129.    (e.g., LAN address- resolution messages) need be forwarded, the need
  130.    to control forwarding should be under the control of higher levels of
  131.    the protocol than may be available to the gateways, (c) Cronus could
  132.    be put into environments where the gateways may be provided by
  133.    alternative vendors who may not implement broadcast propagation, (d)
  134.    as a part of the underlying network, gateways are likely to be
  135.    controlled by a different agency from that controlling the
  136.    configuration of a Cronus system, adding bureaucratic complexity to
  137.    reconfiguration.
  138.  
  139.    Another idea which was rejected was to put broadcast functionality
  140.    into the Cronus kernel.  The Cronus kernel is a process which runs on
  141.    each host participating in Cronus, and has the task of routing all
  142.    messages passed between Cronus processes.  The Cronus kernel is the
  143.    only program in the Cronus system which directly uses broadcast
  144.    capability (other parts of Cronus communicate using mechanisms
  145.    provided by the kernel).  We could either entirely remove the Cronus
  146.    kernel's dependence on broadcast, or add a mechanism for emulating
  147.    broadcast using serially-transmitted messages when the underlying
  148.    network does not provide a broadcast facility itself.  Either
  149.    solution requires all Cronus kernel processes to know the addresses
  150.    of all other participants in a Cronus system, which we view as an
  151.    undesirable limit on configuration flexibility.  Also, this solution
  152.    would be Cronus-specific, while the broadcast-repeater solution is
  153.    applicable to other broadcast-based protocols.
  154.  
  155. 5. Implementation
  156.  
  157.    The broadcast repeater is implemented as two separate processes - the
  158.    forwarder and the repeater.  The forwarder process waits for
  159.    broadcast UDP packets to come across its local network which match
  160.    one or more specific port numbers (or destination addresses).  When
  161.    such a packet is found, it is encapsulated in a forwarder-repeater
  162.    message sent to a repeater process on a foreign network.  The
  163.    repeater then relays the forwarded packet onto its LAN using that
  164.    network's link-level broadcast address in the packet's destination
  165.    field, but preserving the source address from the original packet.
  166.  
  167.    When the forwarder process starts for the first time it reads a
  168.  
  169.  
  170. Lebowitz & Mankins                                              [Page 3]
  171.  
  172.  
  173.  
  174. RFC 947                                                        June 1985
  175. Multi-network Broadcasting within the Internet
  176.  
  177.  
  178.    configuration file.  This file specifies the addresses of repeater
  179.    processes, and selects which packets should be forwarded to each
  180.    repeater process (different repeaters may select different sets of
  181.    UDP packets).  The forwarder attempts to establish a TCP connection
  182.    to each repeater listed in the configuration file.  If a TCP link to
  183.    a repeater fails, the forwarder will periodically retry connecting to
  184.    it.  Non-repeater hosts may also be listed in the configuration file.
  185.    For these hosts the forwarder will simply replace the destination
  186.    broadcast address in the UDP packet with the host's address and send
  187.    this new datagram directly to the non-repeater host.
  188.  
  189.    If a repeater and a forwarder co-exist on the same LAN a problem may
  190.    arise if the forwarder picks up packets which have been rebroadcast
  191.    by the repeater.  As a precaution against rebroadcast of forwarded
  192.    packets ("feedback" or "ringing"), the forwarder does not connect to
  193.    any repeaters listed in its configuration file which are on the same
  194.    network as the forwarder itself.  Also, to avoid a broadcast loop
  195.    involving two LANs, each with a forwarder talking to a repeater on
  196.    the other LAN, forwarders do not forward packets whose source address
  197.    is not on the forwarder's LAN.
  198.  
  199. 6. Experience
  200.  
  201.    To date, the broadcast repeater has been implemented on the VAX
  202.    running 4.2 BSD UNIX operating system with BBN's networking software
  203.    and has proven to work quite well for our purposes.  Our current
  204.    configuration includes two Ethernets which are physically separated
  205.    by two other LANs.  For the past few months the broadcast repeater
  206.    has successfully extended our broadcast domain to include both
  207.    Ethernets even though messages between the two networks must pass
  208.    through at least two gateways.  We were forced to add a special
  209.    capability to the BBN TCP/IP implementation which allows privileged
  210.    processes to send out IP packets with another host's source address.
  211.  
  212.    The repeater imposes a fair amount of overhead on the shared hosts
  213.    that currently support it due to the necessity of waking the
  214.    forwarder process on all UDP packets which arrive at the host, since
  215.    the decision to reject a packet is made by user-level software,
  216.    rather than in the network protocol drivers.  One solution to this
  217.    problem would be to implement the packet filtering in the system
  218.    kernel (leaving the configuration management and rebroadcast
  219.    mechanism in user code) as has been done by Stanford/CMU in a UNIX
  220.    packet filter they have developed.  As an alternative we are planning
  221.    to rehost the implementation of the repeater function as a
  222.    specialized network service provided by a microcomputer based
  223.  
  224.  
  225.  
  226.  
  227. Lebowitz & Mankins                                              [Page 4]
  228.  
  229.  
  230.  
  231. RFC 947                                                        June 1985
  232. Multi-network Broadcasting within the Internet
  233.  
  234.  
  235.    real-time system which is already part of our Cronus configuration.
  236.    Such a machine is better suited to the task since scheduling overhead
  237.    is much less for them than it is on a multi-user timesharing system.
  238.  
  239. 7. Reference
  240.  
  241.    [1]  "Cronus, A Distributed Operating System: Phase 1 Final Report",
  242.         R. Schantz, R. Thomas, R. Gurwitz, G. Bono, M. Dean,
  243.         K. Lebowitz, K.  Schroder, M. Barrow and R. Sands, Technical
  244.         Report No. 5885, Bolt Beranek and Newman, Inc., January 1985.
  245.         The Cronus project is supported by the Rome Air Development
  246.         Center.
  247.  
  248. 8. Editors Note
  249.  
  250.    Also see RFCs 919 and 940 on this topic.
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282.  
  283.  
  284. Lebowitz & Mankins                                              [Page 5]
  285.  
  286.